security: tighten configuration scope for SEC-200#965
Open
EhabY wants to merge 1 commit into
Open
Conversation
Contributor
|
Does the job security wise ✅ cc: @matifali, @zenithwolf1000 |
Collaborator
Author
|
Currently those 18 settings have been moved from
Does it make sense to move these into the |
Collaborator
Author
|
Fair but a lot of these settings are applied prior to establishing an SSH connection and thus it'd be very difficult to set them on the remote machine workspace and have it work consistently |
jdomeracki-coder
approved these changes
May 21, 2026
Mark security-sensitive settings so workspace and folder `settings.json` can no longer override them. VS Code itself drops workspace/folder values for these settings, closing a path where a malicious workspace could redirect command execution (`coder.headerCommand`, `coder.tlsCertRefreshCommand`), swap the CLI binary or its source, inject CLI/SSH flags, substitute TLS material, or override identity and credential-storage settings. Path-, command-, and network-dependent settings use `scope: machine` (per-machine, not synced via Settings Sync). User-wide preferences (`coder.defaultUrl`, `coder.autologin`, `coder.useKeyring`, `coder.insecure`, `coder.disableSignatureVerification`, `coder.enableDownloads`) use `scope: application`, which preserves Settings Sync across machines while still blocking workspace overrides. Bumps to 1.14.6 to match the v1.14.6 tag cut from `release/v1.14.6`.
EhabY
force-pushed
the
security/scope-hardening-sec-200
branch
from
3d3a976 to
4112657
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the SEC-200 attack path where a malicious
.vscode/settings.jsoncould override security-sensitive Coder settings — most notably the two command-execution settings (coder.headerCommand,coder.tlsCertRefreshCommand) called out in the original report.The fix is metadata-only: each affected setting gets
"scope": "machine". VS Code itself drops workspace and folder values formachine-scoped settings, so the malicious workspace value never reaches our code. No runtime guard is needed.Also relaxes the release workflow so a fix can be cut from a release branch (paired with the
release/v1.14.6branch offv1.14.5).Why
machineand notwindow(the default)VS Code's default scope is
window, which means workspace and foldersettings.jsoncan override the user setting. That's precisely the SEC-200 attack vector. Any setting whose value can cause command execution, redirect network traffic, swap credentials, or substitute the CLI binary must not be controllable by a project file — only by the user who installed the extension.Why
machineand notapplicationBoth
applicationandmachineblock workspace/folder overrides, so both close SEC-200. The differences:applicationmachineWe pick
machinebecause most of these settings are inherently machine-specific:cmd.exe /c …headerCommandwould sync over to a Mac via Settings Sync (application) and silently break.binaryDestination,tlsCertFile,tlsKeyFile,tlsCaFile,proxyLogDirectoryare absolute paths that differ per machine.proxyBypass,tlsAltHostdepend on the local network environment.machinekeeps the security guarantee while letting per-machine values stay per-machine, including via VS Code's Remote SSH user-level settings.Settings updated
coder.headerCommandmachinecoder.tlsCertRefreshCommandmachinecoder.binarySourcemachinecoder.binaryDestinationmachinecoder.disableSignatureVerificationmachinecoder.enableDownloadsmachinecoder.sshFlagsmachine-o ProxyCommand=…(exec)coder.globalFlagsmachinecoder.tlsCertFilemachinecoder.tlsKeyFilemachinecoder.tlsCaFilemachinecoder.tlsAltHostmachinecoder.insecuremachinecoder.proxyLogDirectorymachinecoder.proxyBypassmachinecoder.defaultUrlmachinecoder.autologinmachinedefaultUrlcould auto-login elsewherecoder.useKeyringmachineAlready
machine:coder.sshConfig.Settings deliberately left workspace-overridable (no security risk, project-local override is legitimate):
coder.networkThreshold.latencyMs,coder.httpClientLogLevel,coder.disableNotifications,coder.disableUpdateNotifications,coder.experimental.oauth,coder.telemetry.level,coder.telemetry.local.CI change
Drops the
Verify tag is on mainstep from.github/workflows/release.yamlso a security fix can be cut from a release branch (e.g.release/v1.14.6offv1.14.5) without first having to merge everything sitting onmain.Companion PR
A second PR cuts the same fix as v1.14.6 off the
v1.14.5tag for users on the stable channel. This PR delivers the change onmain; it lands under## Unreleasedand will be folded into the next normal release.Test plan
pnpm typecheck— cleanpnpm lint— cleanpnpm test— 1670 passed / 1 skipped, no regressions.vscode/settings.jsonsettingcoder.headerCommand; confirm VS Code reports it as unsettable at workspace scope and the value is ignored.